第三週講的是「自動化」，但回頭看，這六篇其實都在回答同一個問題：當系統開始替你做事，你要怎麼確保它做的是對的事？

排程會排錯時區、免費 API 會限流、資料源會餵毒、VM 會斷電不起、容器會半夜 OOM。自動化的每一分便利，背後都是一分「它壞掉時你不在場」的風險。

這一週做的事，說穿了就是把工作裡看過的那套可靠性思維——SRE 的常識，不是 SRE 的規模——按比例縮小到一台家用 NAS 上。縮小的比例比你想的還大：沒有 SLO、沒有 on-call 輪值、沒有事故等級制度，只有幾支腳本和幾個判斷準則。

今天把六天收斂成四個模式、一段誠實的邊界盤點、一條成本曲線、一份一個人的故障筆記，和一個關於「夠了」的判斷。

Week 3 六天回顧

四個可複用的模式

① 快取隔離（Day 16、17）——外部世界只有一個接觸點。所有對外部 API 的依賴收斂到單一抓取腳本，內部所有消費者只讀本地快取。好處是限流風險集中管理、錯誤處理只寫一次、外部服務掛掉時內部還能靠舊資料運作。這其實就是後端常識裡的 anti-corruption layer，只是規模縮小到一支腳本加一個 JSON 檔。

② 邊界防護（Day 18）——資料進門要驗證，失敗要選最便宜的方式。合理區間檢查、stale 標記透傳、「舊值 > 空值 > 假值」的失敗偏好排序。個人系統沒有資料團隊幫你把關，pipeline 入口的一段 sanity check 就是你的全部防線。

③ 分層監控（Day 20）——動手權要綁在最保守的判斷上。每小時的守衛只對確定性故障出手、其餘一律降級告警，複雜的綜合評價留給一個月才跑一次的體檢報告。反過來配置（把聰明判斷塞進會自動動手的高頻迴路）是自動化系統自傷的標準姿勢。

④ 有限自癒（Day 19、20）——只修「已知病因 + 已驗證藥方」的故障，帶冷卻保險絲，其餘一律降級為告警。這份清單不是設計出來的，是長出來的——怎麼長的，下面〈故障紀錄文化〉那段會講。

四個模式背後是同一個心智轉變：**從「寫功能」變成「經營服務」。**功能寫完就結束了；服務要考慮它在你睡著、出差、忘記它存在時的行為。

誠實盤點：自動化的邊界在哪

上面四個模式聽起來很成套，但我要把話說完，不然這篇會變成一份漂亮的自我推銷。

**這套系統自動化的，是「每天重複而且答案確定」的那一小塊。**其餘的沒有。

具體說，這三件事到現在都是我手動處理的，而且大概會一直是：

① 判斷要不要動。 系統會告訴我「防守部位低於目標」「某個排程連續失敗」「這個月費用比上個月高」，但它從來不決定要不要行動。這是刻意的——Day 20 的自癒清單只收錄「已知病因＋已驗證藥方」，剩下的一律降級成告警。半年下來我沒有後悔過這條線畫在這裡。

② 開發與除錯。 這一週講的每一支腳本、每一道防護，都不是系統自己長出來的。照 Day 1 講好的用字：**判斷要做什麼、邊界畫在哪、驗收過不過，是我；程式碼多半是 AI 助手打出來的。**流程通常是開個對話視窗，把現象貼進去，一起讀 log、一起假設、一起驗證，然後把結論變成程式碼，我讀過、實跑過才部署。

Day 15 我說過一句話，這一週就收在同一個地方——因為它正是整套系統的縮影：**AI 在這套「AI 系統」裡最大的貢獻，是幫我寫出一堆不需要 AI 的腳本。**寫它們的是 AI，跑起來卻一個 token 都不燒。

③ 所有真正重要的決定。 要不要停損、要不要換模型、要不要把某個檢查改嚴——這些都留在我這邊。系統的職責是把判斷所需的資訊準時、準確地端到我面前，不是替我判斷。

所以「自動化」到底自動了什麼

如果重寫這一週的標題，我會寫成：「我自動化的不是決策，是那些讓我看不見狀況的雜事。」

抓資料、算損益、比對閾值、發通知、檢查健康——這些事不做會讓我瞎掉，但做起來一點都不需要智慧。把它們交給腳本之後，我省下來的注意力才有機會用在真正需要人的地方。

這也解釋了為什麼第四週會走向治理：當系統開始替你做事，最大的風險不是它做錯，是你不知道它做了什麼。

可靠性的成本曲線：個人系統做到哪就夠

工作上的 SRE 有 SLA、有 on-call、有多區備援。家用系統照抄是找死——可靠性每加一個 9，成本都是指數上升的。我的取捨畫成曲線大概是：

判斷標準只有一條：**故障的實際代價是什麼？**晨報晚三小時送達，代價是零（我又不當沖）；環境巡檢停一天，代價是牆多受潮一天；唯一真正貴的故障是 API 費用暴走——所以下週的治理，就從它開頭。個人系統的可靠性目標不是「不壞」，是「壞的方式都在預算內」。

想清楚這一點之後，很多焦慮就消失了。我允許系統一年裡有幾天是瘸的，換來的是我不用為了最後一個 9 再投入一倍的心力。過度工程和裸奔一樣，都是沒算過帳的表現。

故障紀錄文化：一個人的 postmortem

這週每篇都出現的隱藏主角，是故障筆記。我在記憶檔案裡維護一份「已知問題清單」，格式固定：現象、根因、解法、（如果有）自動化狀態。半年累積下來十幾條，它們的價值體現在三個地方：

1. 同坑不二跌：WebSocket 斷線這種週期性復發的問題，從「查一晚」變成「查筆記一分鐘」。
2. 自動化候選池：自癒規則全部從這份清單畢業，沒有一條是憑空設計的。
3. 寫成這個系列：你們正在看的每一個「我踩過的坑」，原始素材都是它。

無責備（blameless）這個詞在一人團隊聽起來很好笑——要責備也只能責備自己——但精神是通的：**筆記記「系統哪裡讓錯誤變得容易發生」，不記「我怎麼這麼蠢」。**前者能改，後者只能內耗。

小結＋下週預告

Week 3 的一句話總結：自動化的價值上限由功能決定，下限由可靠性決定——而個人系統的可靠性，是一門「算清楚故障代價再投資」的經濟學。

但有一種故障，我當初完全沒算到代價，它也不在任何監控的視野裡。下週第一篇，就從那個早上說起：2026 年 5 月 4 日，我睡醒打開手機，發現我的 AI 在一夜之間刷掉了 40 美金——而我什麼都沒做。這是整個系列我最想寫、也最不想再經歷一次的一篇。

🔑 這篇的關鍵字
四個可複用模式：快取隔離（anti-corruption layer）· 邊界防護（失敗偏好排序）· 分層監控（頻率 vs 判斷複雜度成反比）· 有限自癒（已知病因＋已驗證藥方＋冷卻）· 個人系統的停損點：做到「壞了會知道、多數能自己爬起來」就夠 · 沒自動化的三件事：判斷要不要動、開發除錯、所有重要決定

我是一名金融業資訊工程師，這是我半年來在家自架 AI Agent 系統的實錄。